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1 Introduction 

This section provides context for the PDRC-IADS research activity, a high-level overview of the 
PDRC concept and an overview of the material presented in this document. 

1.1 Scope 

Future air traffic demands are expected to require a greater degree of integration among the 
automation systems used to manage arrival, departure and surface traffic. The next generation air 
transportation system (NextGen) envisions Integrated Arrival/Dcparturc/Surfacc (IADS) 
operations as described in the JPDO Integrated Work Plan [38] and in the FAA's NextGen Mid- 
Term Concept of Operations [35]. Various NextGen concepts [28, 31, 32] describe IADS 
operations that feature a greater degree of automated coordination as traffic flows from one 
control domain to the next in the tactical air traffic control environment. 

A logical step towards the NextGen vision of fully-integrated arrival/departure/surface 
operations is to automate tactical scheduling of departure traffic that will join a constrained en 
route traffic flow as depicted in Figure 1:1, which is based on Figure 1-1 of Reference 28. 
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PDRC supports the IADS 
concept through integration 
of surface and en route 
decision support tools. 



Figure 1:1 - PDRC supports IADS tactical departure scheduling. 

A commonly used tactical Traffic Management Initiative (TMI) is the Call For Release (CFR) 
procedure, which is also known as the Approval Request (APREQ) procedure. CFR procedures 
vary from facility to facility; however, they generally require the Air Traffic Control Tower 
(Tower) to request approval from the Air Route Traffic Control Center (Center) prior to releasing 
departures headed to specified destinations. Earlier research [20, 21] at NASA Ames focused on 
automating inter-facility coordination during CFR procedures. An FAA-led effort built on this 
work to develop and evaluate the Departure Flow Management prototype [13]. 
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Presently, en route tactical departure scheduling to meet CFR restrictions is often accomplished 
with the Traffic Management Advisor (TMA) decision support tool. Tactical departure 
scheduling with TMA is thoroughly described in Section 0 of this document. 

The Precision Departure Release Capability (PDRC) combines the automated coordination 
demonstrated in the previous research [13, 20, 21] with the use of surface trajectory-based 
takeoff (OFF) time predictions and runway assignments to improve en route tactical departure 
scheduling during CFR procedures. 

PDRC is intended to inform development of mid-tenn NextGen concepts and technologies, but 
PDRC evaluations were conducted in the present-day National Airspace System (NAS) 
environment at a specific location. The scope for this document will be limited to the immediate 
PDRC-IADS research activity as follows: 

System: PDRC research software system developed for evaluations. 

Environment: North Texas (NTX) Research Station and associated FAA facilities: Fort 
Worth Center (ZFW), DFW TRACON (DIO), and DFW Towers. 

Time frame: 2010-2014 for development, evaluation and transition. 

This document includes notes and comments on extending the PDRC concept to other NAS 
environments. 

1.2 Identification 

The PDRC-IADS research activity is an element of the Systems Analysis Integration and 
Evaluation (SAIE) Project of NASA’s Airspace Systems Program. The Aviation Systems 
Division at NASA Ames Research Center is conducting the PDRC-IADS research activity based 
out of NTX. Some of this research activity is being accomplished under a NASA Research 
Announcement contract (NNA1 1AC17C), which was awarded on 23 Sep 2011. Mosaic ATM, 
Inc. is the prime contractor for this work and CSC and Veracity Engineering are subcontractors. 
This document is a joint effort between NASA and contractor personnel. 

NASA and the FAA are coordinating NextGen technology transfer via Research Transition 
Teams (RTTs). The RTTs have defined Research Transition Products (RTPs), consisting of 
distinct concept and/or technology elements that can be transferred as a package. PDRC is one 
of four RTPs currently being coordinated by the IADS RTT. NASA delivered an initial PDRC 
RTP package to the FAA in July 2012. Formal delivery of the core PDRC RTP package is slated 
for the summer of 2013. This ConOps document will be one element of the PDRC RTP 
package. The FAA has identified the Time Based Flow Management (TBFM) Program and the 
Terminal Flight Data Manager (TFDM) Program as recipients of the PDRC RTP. 

1.3 Document overview 

This document describes the PDRC Concept of Operations. Companion documents describe the 
technology that has been developed [2] and the evaluation and analytical results [3]. 

The audience for this document includes the following: 

• The NASA PDRC-IADS team that will use this document to refine the concept 
throughout the research activity. 

• The NASA/FAA IADS RTT, which is facilitating the research transition process. 
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• Other NASA NextGen researchers who may use this ConOps to coordinate research 
within NASA and with external research partners. 

• FAA NextGen implementers who may use this ConOps (and other PDRC research 
products) to infonn development of IADS elements of the NextGen enterprise 
architecture. 


This document strictly follows the IEEE 1362-1998 standard [52] for concept of operations 
(ConOps) documents. IEEE 1362 was selected because it is very similar to the ConOps formats 
described in the FAA’s NAS System Engineering Manual [53] and NASA’s System Engineering 
Handbook [54]. The standard format facilitates review and use of this ConOps by both NASA 
and FAA personnel. 

The FAA’s NAS System Engineering Manual identifies three levels of concept documents (see 
section 4.4. 5.2. of Reference 53) that are differentiated by scope and level of detail. Since this 
ConOps is narrowly focused on the PDRC system, it will likely be considered a concept of use 
(CONUSE) document by the FAA. 

This document is organized as follows: 

Section 1 of the document provides programmatic context, an overview of the ConOps 
document, and an overview of the proposed system. 

Section 2 of the document lists reference documents that relate to the PDRC initiative. 

Section 3 of the document describes the current system. 

Section 4 of the document provides justification for changing the current system, and a 
description of the proposed changes. 

Section 5 of the document describes the proposed system. 

Section 6 of the document details scenarios intended to demonstrate the operation of the 
proposed system and illustrate how the proposed system improves upon the current system. 

Section 7 of the document details operational and organization impacts associated with the new 
system. 

Section 8 of the document presents analyses conducted to quantify the benefits associated with 
implementing the proposed changes. It also presents those options considered and discarded. 

Section 9 of the document presents additional notes. 

Appendix A of the document describes other NextGen research and development initiatives that 
are related to PDRC. 

The Glossary at the end of the document presents a list of acronyms, and their definitions, that 
are used within the ConOps. 


1.4 System overview 

Figure 1 :2 provides a high-level overview of the PDRC operational concept. This figure is 
applicable to both the outbound and inbound tactical departure scheduling situations described in 
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Section 3 of this document. The right side of the figure depicts departure traffic operating under 
the CFR procedure where departures must be merged into constrained en route traffic flows. The 
left side of the figure shows the PDRC decision support tools used for tactical departure 
scheduling. 
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tactical departure 
scheduling. 
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between systems and 
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Surface system predicts 
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Figure 1:2 - Precision Departure Release Capability (PDRC) system overview. 

The upper portion of the figure depicts a traffic stream in the en route domain that is under a 
CFR constraint. PDRC builds on an existing tactical departure scheduling decision support tool 
used by the Center to schedule departures into this constrained overhead stream. Ascent 
modeling in the en route decision support tool enables precise time-based scheduling and de- 
confliction at the meter point. The modeled ascent trajectory is illustrated by the gold line in 
Figure 1:2. 

The lower portion of Figure 1 :2 depicts the Tower environment where a NextGen surface 
trajectory-based decision support tool is in use. NextGen surface trajectory-based operations are 
enabled by a surface surveillance system and air carrier data sharing that provides intent and 
status information (e.g., gate assignments, estimated and actual pushback times). The surface 
trajectories computed and used by this decision support tool are represented by the blue and red 
lines in this figure. 

PDRC focuses on the automated communication and use of surface trajectory-based OFF time 
predictions and runway assignments for tactical departure scheduling in CFR situations. In 
present-day operations, OFF time prediction and communication is manual. Automated PDRC 
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communication is illustrated by the double -headed arrow on the left side of Figure 1:2. The 
Center decision support tool uses surface trajectory-based OFF time predictions for departure 
scheduling and coordinates release times with the Tower surface trajectory-based decision 
support tool. The Tower tool predicts OFF times and runway assignments for use by the Center 
tool in tactical departure scheduling and coordinates release times with the Center decision tool. 

The focal point for PDRC is the OFF event in Figure 1 :2 where the red trajectory joins with the 
gold trajectory on the departure runway. The Tower decision support tool computes surface 
trajectories to this point to develop OFF time estimates. The Center decision support tool 
computes ascent trajectories from this point to the merge point in the overhead stream for tactical 
departure scheduling. 
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3 Current system 

The PDRC system addresses shortfalls in present-day tactical departure scheduling situations. 
This section defines tactical departure scheduling and describes how it is accomplished today in 
the NAS. 

3.1 Background, objectives, and scope 

Tactical departure scheduling is a process used by Traffic Management Coordinators (TMCs) to 
regulate air traffic flow to eliminate local demand/capacity imbalances and meet requirements of 
local traffic management initiatives (TMIs). Tactical departure scheduling is not required during 
normal NAS operations, as the airspace into which the flight is being released generally has 
sufficient capacity to accommodate the departure. However, during periods of high demand or 
low capacity for the airspace being scheduled into, tactical departure scheduling may then be 
utilized. 

3.1.1 Tactical versus strategic departure scheduling 

While a significant amount of literature exists on strategic departure scheduling in the NAS, 
information on the tactical departure scheduling process is quite limited. Thus, a NAS-wide 
analysis of departure scheduling operations [5] was first performed by the PDRC research team. 

Tactical and strategic departure scheduling processes are distinct from one another and are 
currently not directly integrated. Tactical departure scheduling is distinguished from strategic 
departure scheduling based upon scope (both temporal and geographic), precision requirements, 
and the decision support tools used [5]. Strategic departure scheduling primarily uses the Traffic 
Flow Management (TFM) tool suite, while tactical departure scheduling is typically 
accomplished with the Traffic Management Advisor (TMA) decision support tool [26]. 

A significant difference between tactical and strategic departure scheduling is the scope of the 
initiative. Strategic departure scheduling is focused on correcting large demand/capacity 
imbalances that exist in the NAS, usually due to convective weather or high demand. This often 
requires significant delays over an extended period of time, which may be assigned hours in 
advance of the affected aircraft’s departure time. In contrast, tactical departure scheduling 
focuses on a specific air traffic flow that is subject to a local traffic management initiative (like 
Miles in Trail or Adjacent Center Metering), and generally introduces small delays to specific 
aircraft on an as-needed basis. Tactical departure schedules are able to consider the latest 
airspace conditions minutes before takeoff. 

Tactical departure scheduling system delays are approximately 4 minutes per aircraft, on 
average, with a median of 1 minute. This delay is significantly lower than TFM delays, with 
approximately a 66 minute average and a 52 minute median delay. These statistics are derived 
from January 2011 NAS operational data [5]. 

The study of January 2011 NAS operational data also examined the relative frequency of tactical 
and strategic departure scheduling. Figure 3:1 uses the large gray ellipse to depict the entire set 
of domestic flights in the NAS (more than 1 million) for that month. Departures subject to 
strategic traffic management initiatives are shown in the orange ellipse. Tactical departures are 
shown in the 3 green ellipses. There were approximately 3.5 times as many tactical departures as 
strategic departures in January 2011. 
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Figure 3:1 - Strategic and tactical departure scheduling for January 2011. 

The results shown in Figure 3:1 distinguish between inbound and outbound tactical departures. 
These two types of tactical departure scheduling are described in detail in Section 3.3. Inbound 
is associated with TMA arrival metering and outbound is associated with TMA’s En Route 
Departure Capability (EDC) function. 

For this analysis, an aircraft was counted as being tactically scheduled only if the aircraft was 
both scheduled and ‘accepted’ or ‘frozen’ into the TMA Arrival or EDC system. A significant 
number of aircraft (approximately 18,489 during January, 2011) were initially scheduled in the 
TMA system, but the scheduling process was not finalized by either “accepting” or “freezing” it. 
This suggests an even larger pool of tactical departure operations may exist. 

It is worth noting that inbound tactical departure scheduling occurred about five times more 
frequently than outbound tactical departure scheduling in January 2011 operations. 

3.1.2 Prevalence of tactical departure scheduling in the NAS 

Analysis of NAS operational data also provided insights into the prevalence of tactical departure 
scheduling. Reference 5 notes that TMA’s EDC function is deployed to all 20 Centers. Data 
presented in Figure 4 of that paper indicate that EDC is commonly used for outbound tactical 
departure scheduling at about half of the Centers. 

As described in Reference 4, inbound tactical departure scheduling is largely dependent on TMA 
adjacent center metering infrastructure. Figure 3:2 presents an overview of inbound tactical 
departure scheduling operations. The base image, courtesy of the FAA, depicts TMA adjacent 
center metering installations in the NAS as of March 2010. The base image shows the 20 Centers 
as green “puzzle piece” polygons. 
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Figure 3:2 - Centers using inbound tactical departure scheduling in January 2011. 

Operational TMA data were analyzed [5] to identify sites where inbound tactical departure 
scheduling operations occur. The survey results are plotted in Figure 3:2 as overlay symbols. 

The Centers conducting inbound tactical departure scheduling have been labeled with round 
yellow “O” and square orange “D” symbols. The “O” label indicates Centers that schedule their 
departures into the arrival TMA system of one or more adjacent Centers. The “D” label identifies 
Centers that permit adjacent facilities to schedule departures into their arrival TMA system. The 
one “O” label in the northeast that is not associated with a Center represents the inbound tactical 
departure scheduling from Nav Canada to New York Center (ZNY). Figure 3:2 shows that 18 
Centers (plus Nav Canada) schedule departures into another Center’s TMA system, while 10 
Centers receive inbound tactical departure schedules from other facilities. 

3.2 Operational policies and constraints 

Tactical departure scheduling is not required during normal NAS operations. It is predominantly 
used when tactical restrictions on the airspace have been imposed. A common TMI requires the 
use of the CFR procedure, also known as the Approval Request (APREQ) procedure. CFR 
procedures are used to address local demand/capacity imbalances and ensure local traffic 
management initiatives are satisfied. Note that the locally implemented CFR procedure may be 
in response to a constraint that is propagated from elsewhere in the NAS. 

CFR procedures vary from facility to facility; however, they generally require the Tower 
personnel to call the Center for a scheduled departure time, prior to releasing the aircraft for 
departure. The CFR procedure is applied to departing aircraft in order to ensure the demand 
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placed on local airspace resources en route to or at the destination airport does not exceed the 
available capacity. The CFR procedure may be applied in both the outbound and inbound tactical 
departure scheduling modes. 

In a CFR scenario, it may or may not be necessary to delay the aircraft based upon the latest 
information available on the constrained flow at the time that an aircraft is ready to depart. The 
improved departure time compliance associated with the CFR procedure provides more accurate 
schedule predictions than are available via the aircraft’s filed flight plan departure time (also 
kn own as Predicted Departure Time, or PTIME), or via Expect Departure Clearance Times 
(EDCTs). EDCTs are generated by TFM as a part of the strategic departure scheduling system 
and are not intended for tactical use. Aircraft PTIMEs represent a starting point from which the 
departure planning process can begin, but are historically prone to OFF time uncertainty [23, 27]. 

The required departure compliance window for CFR aircraft has also varied somewhat by 
facility. Many facilities, including ZFW and DFW, have employed a -2/+1 minute compliance 
window for CFR operations. A recent FAA Notice [39] has established the -2/+1 window as a 
national standard for TMA operations by amending FAA 71 10.65 standing order to read “when 
CFR is in effect, release aircraft so they are airborne within a window that extends from 2 
minutes prior and ends 1 minute after the assigned time, unless otherwise coordinated.” The 
compliance window is biased to favor early departures because it is easier to slow an early 
departure to fit into a slot than it is to accelerate a late departure. 

3.3 Description of the current system 

As noted above, the TMA decision support tool includes two distinct modes for tactical 
departure scheduling: inbound scheduling of departures into an arrival stream of a TMA-metered 
airport, and outbound scheduling of departures from an airport within the departure Center to a 
remote Center. 

Examples of inbound and outbound tactical departure scheduling situations are presented in the 
following subsections. These descriptions use real-world situations to illustrate how the tactical 
departure scheduling modes are implemented today. The examples feature ZFW and DFW 
because this is the locale for the initial PDRC field evaluations. However, these situations are 
representative of current tactical departure scheduling situations found throughout the NAS. 

3.3.1 Inbound tactical departure scheduling capability 

Inbound tactical departure scheduling uses the TMA arrival metering “internal departure” 
function to schedule departures into the inbound arrival streams of a TMA-metered airport. 

These inbound departures may originate from the TMA system’s home Center, another Center, 
or even other countries (e.g., Canadian flights scheduled into New York Center’s TMA system 
via the international TFM interface). 

Figure 3:3 shows an example of an inbound tactical departure scheduling situation. In this case, 
the green arrows show various traffic streams destined to Houston’s George Bush 
Intercontinental Airport (IAH). These streams pass through ZFW airspace and converge at the 
TORNN meter arc (73nm radial distance northwest from the RIICE fix), which is situated at the 
southern boundary of ZFW. In TMA terminology, the TORNN arc is an “outer metering arc.” 
TMA distributes the delay an aircraft must absorb to various meter reference points (i.e., 
metering arcs and fixes) situated along the arrival path. Metering at the TORNN arc is actually 
performed by ZFW controllers prior to departure, using information provided by the ZHU TMA 
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system via the adjacent center metering infrastructure. As part of the scheduling process, a 
release time is computed for the DFW departure and communicated to the Tower via the CFR 
procedure. Given that DFW resides within the IAH metering freeze horizon and there is limited 
airspace available to maneuver after departure prior to the outer meter arc, a high level of 
departure prediction accuracy is required. 

Tactical scheduling of departures inbound to a TMA-metered airport using "internal 
departure" schedulingfunctions of TMA arrival metering system 



Figure 3:3 - A typical inbound tactical departure scheduling situation. 

Note that not all inbound tactical departure scheduling is from an adjacent center. For instance, 
Indianapolis Center schedules into New York Center, although the two Centers do not share a 
boundary. Another unique case occurs when aircraft departing Canadian airspace are managed 
via CFR into New York Center airspace. 

3.3.2 Outbound tactical departure scheduling capability 

Outbound tactical departure scheduling uses TMA’s EDC function to tactically schedule flights 
departing from airports within the TMA system’s home Center outbound into constrained en- 
route streams or airspace. Whether the flight’s destination is in the adjacent Center or across the 
country, this situation is considered tactical because EDC is being used to address local 
demand/capacity imbalances and because scheduling is to a meter point in the home Center. 

The EDC system design re-uses a number of common components of the arrival TMA system, 
such as its adaptation data structure, route processing algorithms, and trajectory generation 
functions. While many of the core components of TMA have been leveraged to provide EDC 
capability, there are notable differences between arrival TMA and the EDC system. 

The EDC system serves a different traffic management objective than the arrival TMA system. 
EDC’s focus is outbound tactical departures leaving from one or more of the airports within a 
Center that are destined to a remote Center facility. In contrast, the tactical departure scheduling 
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capability in the arrival TMA system is only focused on aircraft that are scheduled into its 
metered airports. EDC is commonly used to assist in the application of miles in trail restrictions 
between facilities, especially when the airspace being scheduled into is highly constrained or has 
multiple miles in trail initiatives to satisfy. An additional use of EDC is to assist in regulating 
departures into sectors that are experiencing high demand. In contrast, arrival TMA use is 
primarily motivated by the traffic volume in the arrival streams entering the metered airport 
rather than by sector loading considerations. 

Figure 3:4 shows an example of an outbound tactical departure scheduling situation. The figure 
depicts the southeastern portion of the United States. State boundaries are shown in grey while 
Center boundaries are shown in purple. The green arrows depict a cross-country, overhead traffic 
stream destined to Atlanta’s Hartsfield- Jackson International Airport (ATL). The overhead 
stream transits ZFW airspace, crossing directly over DFW, and continues to ATL via the 
Meridian (MEI) fix. The gold arrow depicts the ascending flight of a DFW departure that must 
merge with the overhead stream of ATL-bound traffic. 

Tactical scheduling of departures outbound from home ARTCC using Traffic 

Management Advisor (TMA) En Route Departure Capability (EDC) 



Figure 3:4 - A typical outbound tactical departure scheduling situation. 

The DFW departures merge with the overhead stream at the MEI arc (155 nmi radial distance 
west from the MEI fix) located on the extreme eastern edge of ZFW. This arc serves as a meter 
reference point for TMA’s EDC function. TMA EDC uses four-dimensional (4D) trajectory 
synthesis, including aircraft performance models and current forecast winds, to calculate an OFF 
time that will enable the aircraft to rendezvous with the identified slot at the meter point. 

The ATL flow shown here represents a fairly common CFR situation for ZFW. However, ZFW 
uses EDC for outbound tactical departure scheduling to Houston-area airports approximately 
four times more often than for ATL. 
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3.3.3 Clarifying inbound vs. outbound tactical departure scheduling 

The inbound and outbound labels were coined to address confusion associated with the two 
distinct departure scheduling functions in TMA. The TMA EDC function is clearly identified as 
a departure capability; however, it is currently used about 5 times less frequently than arrival 
TMA’s “internal departure” scheduling function. The situation is even more confusing when one 
considers that arrival TMA “internal departures” are now frequently external to the home Center 
with the widespread deployment of adjacent center metering. 

The inbound and outbound labels are referenced to the TMA system being used for departure 
scheduling. Thus, it is important to have a clear mental picture how TMA is used for tactical 
departure scheduling in the present-day NAS. Figure 3:5 depicts both inbound and outbound 
tactical departure scheduling applied to the same constrained overhead stream. 



meter point. 



\ TMA metering at arrival Center. 
Trajectory-based scheduling to 
arrival runway using “internal 
departure” functions. 


Figure 3:5 - Clarifying “inbound” and “outbound” labels for TMA tactical 
departure scheduling. 


Figure 3:5 shares common image elements with Figure 1:2, Figure 3:3, and Figure 3:4. The 
tactical departure trajectory is shown in gold and joins the constrained overhead flow at a meter 
point shown in red. The departure airport is on the left located inside the departure Center shown 
in blue. The arrival airport is on the right, located inside the arrival Center, shown in green. 

The constrained overhead stream is shown flowing from left to right from the blue Center to the 
green Center, where the stream becomes an arrival flow to the airport on the right side of the 
figure. Two separate TMA systems are depicted by timeline user interface icons with “Center 
DST” labels. 

Consider first the outbound tactical departure scenario. In this case traffic managers at the blue 
Center would use the blue TMA/EDC system to schedule CFR departures from the airport on the 
left into the constrained overhead stream. The traffic managers are using their own TMA/EDC 
system to schedule traffic outbound from their own Center. In this case, the constrained 
overhead flow happens to be an arrival stream for an airport in the adjacent Center, but it is 
treated like any other outbound flow for scheduling purposes. 
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Now consider the inbound tactical departure scenario. In this case, the departure from the 
airport on the left is scheduled into the green TMA system, which is being used by the green 
Center to meter the arrival stream to the airport on the right. The CFR call and tactical departure 
scheduling action is most likely being performed by traffic managers in the blue Center using an 
interface to the green Center TMA system. Thus, the blue Center traffic managers are using the 
green Center TMA system to schedule traffic inbound to the airport on the right. 

The situation depicted in Figure 3:5 is a common occurrence. Consider the blue Center to be 
ZFW and the green Center to be ZHU with the arrival airport on the right being IAFI. Some days 
ZHU will meter arrival flows to IAH and ZFW traffic managers will follow the inbound tactical 
departure scheduling process for those flow. On other days, ZHU will use a MIT restriction on 
the IAH flows and ZFW traffic managers will manage departures with the outbound process. 

3.3.4 Current tactical departure scheduling process 

Current tactical departure scheduling procedures in place at DFW during a Call for Release 
restriction require increased communication/coordination between the controllers. The process is 
as follows: 

1 . Center calls the Towers to notify of the Call For Release restriction. 

2. The Tower enters the restriction in the currently available coordination tool (e.g., 
Integrated Display System #5) 

3. Tower TMC and/or other personnel (e.g., frontline manager) monitor all flights as they 
become ready for departure to detennine if they are subject to the call for release 
restriction. 

4. When an aircraft subject to Call For Release becomes ready for departure, the TMC calls 
the Center and requests a release time. 

5. Center types the manually communicated time in their automation tool, which provides a 
departure time that incorporates any required delay to fit into the overhead stream. The 
resulting time is communicated back to the Tower TMC in the fonn of a Call For Release 
window. 

6. Tower evaluates the situation on the airport surface and determines if the Call For 
Release time can or cannot be met. If the TMC believes the time is feasible then it is 
communicated to local controller. If not, then a new time is negotiated between Center 
and the Tower. 

Any holding of the flight due to the CFR will occur in the departure queue or at the runway 
threshold. 


3.4 Modes of operation for the current system 

The NASA PDRC-IADS research team has observed the FAA operational tactical departure 
scheduling system operating in the following modes: 

• Operational (i.e., operational system nominal use) 

• Maintenance (i.e., support string utilization) 
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3.5 User classes and other involved personnel 

The scope of this ConOps is specifically limited to the field evaluation environment for the 
PDRC-IADS research activity (i.e., NTX, ZFW, DIO, and DFW). FAA recipients of this 
ConOps should be able to extrapolate the comments to other operational environments. 

Users of the current system include 

• ZFW Center TMCs and STMCs 

• DIO TRACON TMCs and STMCs 

• DFW Tower TMCs, STMCs and FLMs 

3.6 Support environment 

The NASA PDRC-IADS research team has observed the following support environment 
elements for the FAA operational tactical departure scheduling system: 

• ZFW TMA support string hardware in use 

• ZFW TMCs and STMCs testing new releases and modifying system configuration 

• ZFW, DIO, and DFW TechOps personnel providing hardware support 

• ZFW AOS personnel providing adaptation support 

• WJHTC second level support personnel providing various support 

• TMA National Team providing oversight and support 
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4 Justification for and nature of changes 

This section describes the shortcomings of present-day tactical departure scheduling operations 
and describes the desired changes. 

4.1 Justification for changes 

The underlying problem that motivates this research is that of an aircraft departing from the 
airport surface into a constrained flow, like that illustrated in Figure 4:1. The primary challenge 
associated with present-day tactical departure scheduling is that OFF time predictions used in 
this process are manually estimated and coordinated. 




Manual OFF Estimate 
Manual Coordination 
Manual Data Entry 


Figure 4:1 - Tactical departure scheduling - the problem. 

The anticipated PDRC benefits include 

• Reduced tactical departure scheduling uncertainty, which will result in 

o More reliable departure meter point times 
o More efficient departure metering operations 
o Fewer missed and/or spoiled departure slots 
o Tighter tolerances for departure scheduling 

• Ready identification of aircraft that require no action to meet CFR constraints, thus 
reducing inter-facility coordination requirements 

• Dynamic alerts providing advance notice when aircraft will be unable to meet scheduled 
OFF time due to changes in the surface traffic situation 

• Reduced workload due to automatic computation of OFF time predictions and automatic 
communication between surface and en route automation systems 

Analysis of the current system’s performance indicates that significant room for improvement 
exists by reducing departure time uncertainty and manual coordination. NAS-wide operational 
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data analysis for January 2011 [5] showed nearly 6,800 inbound tactically scheduled aircraft and 
more than 1,900 outbound tactically scheduled aircraft that are estimated to have missed the 
airspace slot they were scheduled into because of departure time prediction uncertainty. The 
effect to the NAS of a missed scheduled departure slot often leads directly to lost capacity, most 
notably in the case in which an aircraft is scheduled as frozen into an arrival TMA slot but does 
not meet its expected departure time window. Measuring the impact to the NAS of a missed 
departure slot is not straight forward, as some ability to recover the airspace resource exists, but 
generally at a cost. 

An additional shortfall of the current inbound system occurs when the tactical departure delays 
become very large. This situation may require Air Traffic Control System Command Center 
(ATCSCC) involvement. When high, tactically-assigned ground delay occurs in the NAS, the 
ATCSCC may choose to implement an Airspace Flow Program (AFP) to regulate the flow of 
aircraft into the destination airport, with the objective of reducing the TMA-assigned surface 
delays. The AFP scheduling scenario used for this purpose is unique in that it is designed to work 
in conjunction with the arrival TMA system; hence, it is called a TMA Flow Program (TFP). 

The objectives of a TFP are to pre-condition the arrival stream such that TMA can utilize 
available space in the stream for tactical departure scheduling purposes. The boundaries of the 
TFP are set to be roughly contiguous with the arrival metering system’s freeze horizon and any 
airport with departures inside of this boundary are exempt from the program. Using a TFP, the 
TFM suite of tools assigns a ground delay to aircraft bound for the metered airport that are 
located outside of the red circle shown in Figure 4:2, while TMA assigns a tactical ground delay 
(and potentially airborne delay, depending on the TMC selection) for those aircraft bound to the 
metered airport located within the red circle [16]. 



We 


TFP scheduling flights to a 
390 nmi circle (FCA) 

• Flights outside the circle 
assigned departure delays 

• Flights inside the circle 
exempt from the TFP 


Figure 4:2 - Example of TMA Flow Program into Atlanta. 


4.2 Description of desired changes 

The following changes were required for the PDRC field evaluations: 
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• Develop a research version of the operational FAA TMA/EDC system (called Research 
TMA [rTMA]) 

• Update NASA’s Surface Management System (SMS) research tool to incorporate the 
latest FAA SDSS enhancements 

• Develop a two-way interface and enhance rTMA and SDSS to enable automatic 
communication and use of SDSS trajectory-based OFF time predictions in rTMA 
departure schedule computations 

• Integrate PDRC components (rTMA and SDSS) in the NTX environment 


All of these changes have been accomplished, and the components utilized during shadow and 
operational evaluations. A detailed description of the required changes can be found in the 
companion Technology Description document [2], 


4.3 Priorities amongst changes 

Essential changes required to the system to enact the change in operations described are 
explained in detail in the program level requirements in the Technology Description document 
[2], as well as how the PDRC team met those requirements. 

Determining priorities amongst optional features is likely best left to FAA personnel that will 
implement these changes in their native systems (e.g., TBFM and TFDM). As an example, user 
interface improvements were lower priority to the PDRC research team than ensuring the core 
data interfaces and algorithms were properly functioning. However, the FAA may have a 
different priority amongst changes. 


4.4 Changes considered but not included 

This section summarizes ideas that have been considered but not included in the PDRC system. 

A number of potential capabilities for PDRC were not pursued due to the emphasis on realizing 
near-term benefits. Other capabilities were not considered due to resource limitations or the 
relative immaturity of certain research areas. Some of the potential changes are already planned 
for implementation in PDRC follow-on research. Changes that could fit into the near-term scope 
of PDRC that were considered but not included were as follows: 


• Initiate a call for release from the TMA/EDC data that is being passed to the surface 
system rather than requiring the surface user to enter it manually 

• Re-evaluate the use of color coding of surface flight status on minutes-level precision 
now that seconds-level precision is in use 

• Allow for an APREQ and/or EDCT aircraft to be placed on the timeline at their 
scheduled time rather than un-delayed OFF time 

• Improve communication and setup of APREQs in the surface system to address 
situations where turboprops should be included (inbound scenario) versus situations 
where turboprops should be excluded (outbound scenario) 

• Handle ‘flight stubbing’ data from carrier so that these flights match filed flight plans 
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Pass along the route 10b information available to rTMA and process it within the 
surface system to allow for improved departure fix mapping 

Limit the runways available for selection on the surface system to those in the current 
airport configuration 

Allow more options for color coding aircraft on the surface display based upon flight 
characteristics (e.g., aircraft has APREQ) 

Change aircraft symbol on surface display (FAA request) 

Dynamically change an aircraft's data tag values as the flight progresses; for example, 
initially show the parking gate while parked, then switch to the estimated spot after 
OUT, then switch to the estimated RWY after entering the AMA, and then, after OFF, 
switch to the departure fix (FAA request) 

Provide a “what if’ capability that allows the user to adjust the state for an individual 
aircraft and then elect to either apply the new state or reset back to the saved state (FAA 
request) 

Enable a “Bulk Move,” a bulk aircraft runway swap capability. Aircraft destined for 
particular, multiple selectable, departure fixes could be selected in addition to a 
particular runway. For example using the DIO south gate, aircraft destined to be over 
NELYN, JASPA, ARDIA, could be moved while leaving DARTZ aircraft alone. These 
moves would be temporally selected. It was also suggested that when moving aircraft 
from one side to the other that default east/west runways be set (by flow direction) so as 
to further simplify the move. (FAA request) 

Enable Drag and Drop. This enhancement, requested by a D10/DFW STMC, would 
make it possible to drag and drop aircraft on a timeline. This came up in the context of 
airport runway balancing using SDSS as a pre-departure planning tool. In addition, 
enable drag and drop on rTMA with surface data (FAA request) 

Display TMA data on SDSS timelines; this is part of a general request to allow greater 
visibility of TMA’s predictions in the overhead stream on the surface display 

Enable airline interface ‘daisy chain’ ability 

Improve PDRC’s data feed robustness 

Improve handling of an aircraft with both an APREQ and EDCT 
Improve ‘suspend’ logic handling 

Obtain and use cancellation indicator from airline interface (Note: already in secondary 
interface) 

Improve handling of surface time updates while Center user is in the process of 
scheduling (FAA request) 

Verify that multiple surface interfaces can be handled by rTMA 

Update the rTMA status message for surface flights to be automatically removed when 
associated work is done (FAA request) 


Improve filtering of surface flights panel (Shift-F4 panel) 


4.5 Assumptions and constraints 

The following are assumptions used in the development of this Concept of Operations: 

• A surface system will exist in the National Airspace system that is capable of providing 
OFF time predictions and runway assignments to the en route system similar to those 
provided by SDSS in PDRC 

• An en route system will exist in the National Airspace System that is capable of receiving 
surface information and providing coordinated release times similar to those provided by 
the rTMA system in PDRC 

• The surface and en route system will have access to data inputs similar to those used in 
PDRC (e.g., gates assignments, surface surveillance, en route surveillance, weather, flight 
planning data) 

• The system used to automate coordination during CFR events must perform at least as 
well as (preferably better than) the current manual process in use today. Failure to do so 
could lead to local personnel refusing to utilize the automation. 

• Some ability for site-specific adaptation related to surface/en route automation will exist. 
The desire is to keep site specific adaptation to a minimum 

• Adequate training for changes proposed will be provided to end users 


23 


5 Concepts for the proposed system 

This section describes the PDRC system that has been developed to address shortfalls in present- 
day tactical departure scheduling. 


5.1 Background, objectives, and scope 

The PDRC-IADS research activity combines the automated coordination demonstrated in 
previous research [13, 20, 21]with the use of surface trajectory-based OFF time predictions to 
improve en-route tactical departure scheduling during CFR procedures. PDRC-IADS 
background, objectives, and scope are presented in Section 1. 


5.2 Operational policies and constraints 

Per the statement in Section 1, the scope of this ConOps is specifically limited to the field 
evaluation environment for the PDRC-IADS research activity (i.e., NTX, ZFW, DIO, and DFW). 
FAA recipients of this ConOps should be able to extrapolate the comments to other operational 
environments. 

The PDRC operational evaluations [3] were conducted within the standard CFR procedures 
followed by ZFW and DFW. In other words, the TMCs have not been asked to modify 
procedures other than to use the PDRC research system. 

The PDRC operational evaluations were conducted only in the ZFW outbound (i.e., TMA/EDC) 
tactical departure scheduling scenario. Operational evaluations of the inbound scenario were not 
possible due to challenges of using rTMA for operational arrival metering at ZHU. See Section 
5.4 of the Final Report [3] for a discussion of inbound scenario field evaluation challenges. 

5.3 Description of the proposed system 

A high-level overview of the proposed system is provided in Section 1.4. That overview and the 
accompanying figure presented the double-headed arrow as the essence of PDRC. The arrow 
represents the automatic communication and coordination of OFF times between the en route 
tactical departure scheduling system and a trajectory-based surface automation system. 

5.3.1 PDRC applied to tactical departure scheduling 

Section 3.3 provided examples of inbound and outbound tactical departure scheduling situations 
and described how TMA’s departure scheduling functions were used in these situations. This 
section uses a revised version of Figure 3:5 to illustrate how PDRC is applied to tactical 
departure scheduling. 

Figure 5:1 shows a NextGen trajectory-based surface automation system communicating with 
the TMA systems via the PDRC double-headed arrow. As described in the Section 1 .4 
overview, the surface system delivers OFF time predictions and runway assignments to TMA to 
improve tactical departure scheduling. The double arrow is also used to automatically 
communicate the TMA-computed release time back to the surface system for use by the Tower 
controller team. 
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PDRC has been 
developed for both the 
Outbound and Inbound 
scenarios. 


Figure 5:1 - PDRC applied to tactical departure scheduling. 

As shown in Figure 5:1, PDRC has been developed for both the inbound and outbound cases. 

The prototype software supports both cases, although the operational evaluation only evaluated 
the outbound case. 

5.3.2 PDRC prototype software 

The PDRC research activity strives to be implementation neutral, meaning that the research 
results will be generally applicable, regardless of which specific surface or en-route tools are 
used. PDRC performance will, however, be affected by the prediction and scheduling accuracy 
of the component systems that are used. The PDRC Technology Description document [2] 
includes requirements for the two component systems as well as information exchange 
requirements. The prototype software used for development and evaluation may not reflect 
eventual implementation systems. 

A high-level overview of the prototype software used for the PDRC concept testing is illustrated 
in Figure 5:2. The upper portion of this figure shows the Center tactical departure scheduling 
decision support tool. The PDRC prototype utilizes rTMA for this component. The lower portion 
of this figure shows the Tower decision support tool. The PDRC prototype uses SDSS for this 
component. Complete details regarding the PDRC prototype software are provided in the 
Technology Description companion document [2]. 
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Figure 5:2 - PDRC prototype software overview diagram. 


5.4 Modes of operation for the proposed system 

The PDRC research prototype system has been operated in the following inodes: 

• Production (i.e., operational field evaluation) 

• Training (i.e., on-the-job training for TMCs prior to field evaluation) 

• Degraded (e.g., single center Host data when multi-center unavailable) 

This ConOps considers both nominal and off-nominal modes of operation. 


5.5 User classes and other involved personnel 

Per the statement in Section 1, the scope of this ConOps is specifically limited to the field 
evaluation environment for the PDRC -IADS research activity (i.e., NTX, ZFW, DIO, and DFW). 
FAA recipients of this ConOps should be able to extrapolate the comments to other operational 
environments. 

Subject-matter expert participation in the PDRC operational evaluations has included traffic 
managers (TMCs and STMCs) at ZFW Center, DIO TRACON, and DFW Towers, as well as 
frontline managers (FLMs) at DFW. Test participants will be generically identified as TMCs in 
the discussion that follows. 
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5.6 Support environment 

Per the statement in Section 1, the scope of this ConOps is specifically limited to the field 
evaluation environment for the PDRC-IADS research activity (i.e., NTX, ZFW, DIO, and DFW). 
FAA recipients of this ConOps should be able to extrapolate the comments to other operational 
environments. 

The PDRC prototype system is entirely supported by the PDRC-IADS research team at the 
NASA North Texas (NTX) Research Station for the duration of the development and evaluation 
period. 
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6 Operational scenarios 

The primary scenario for the PDRC Block 1 field evaluation is the Call for Release (CFR) traffic 
management procedure applied to DFW departures and implemented with the outbound tactical 
departure scheduling (i.e., TMA/EDC). 

6.1 CFR procedure overview 

The CFR procedure is a collaborative effort between the Center traffic management unit 
responsible for meeting the overhead stream constraints and the Tower controllers responsible 
for releasing departing aircraft. The PDRC concept automates portions of this collaborative 
departure scheduling effort. Specifically, PDRC’s SDSS component automatically predicts the 
earliest achievable OFF times for all departure flights. For flights subject to CFR restrictions, the 
SDSS OFF time predictions are automatically communicated to rTMA for use in tactical 
departure scheduling functions. The PDRC two-way interface facilitates inter-facility 
coordination required to establish an agreed upon release time. 

As described in Section 3.2, a recent FAA Notice [39] has established the -2/+1 CFR 
compliance window as a national standard for TMA operations by amending FAA 71 10.65 
standing order to read “when CFR is in effect, release aircraft so they are airborne within a 
window that extends from 2 minutes prior and ends 1 minute after the assigned time, unless 
otherwise coordinated.” The compliance window is “biased” towards being early because it is 
easier to slow an early departure to fit into a slot than it is to accelerate a late departure. Tactical 
CFR precision requirements are significantly higher than for strategic TMIs [5]. Even so, the 
three-minute window is rather imprecise when one considers that this equates to a 2 1 to 24 mile 
slot at the en route meter point. 

Rather than prescribe a window that the surface controller must meet, PDRC communicates the 
target time of departure at seconds-level granularity to the Traffic Manager in the tower. 
Communicating this time at seconds-level granularity removes any rounding of the data that 
would be done by the Center system or personnel, ensuring the exact target time is known by the 
traffic manager in the tower. PDRC also has the ability to adjust the time passed from the Center 
automation if necessary to bias the time to achieve the objective. The TMC then uses the 
electronically communicated time in seconds-level precision and rounds this value, as 
appropriate, before passing it along to the local controller. The local controller then works to 
meet the time as closely as possible with the understanding that it is better to be early than late. 

It should be noted that application of PDRC automation does not fundamentally alter the CFR 
procedure. Center and Tower roles and responsibilities may remain the same, and CFR 
operations may be conducted per existing inter-facility Letters of Agreement. TMA is widely 
used for tactical departure scheduling to meet CFR restrictions, and TMC interactions with the 
TMA departure scheduling functions are essentially unchanged with the PDRC system. Thus, 
only the SDSS-related portions of the following scenario represent material changes to the 
present-day CFR procedure. 

Figure 6:1 presents an overview of the Tower and Center interactions involved in tactical 
departure scheduling with PDRC to implement the CFR procedure. The left side of the figure 
shows the Center TMC interacting with the rTMA user interface. The right side of the figure 
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shows the Tower TMC interacting with the SDSS user interface. Center and Tower TMC 
actions are listed in the center portion of the figure. 




Center notifies Tower of CFR 
restrictions via standard procedure 


Tower enters restrictions into SDSS 
SDSS sends updated OFF time and 
runway predictions to rTMA 


rTMA re-computes en route 
schedules using SDSS predictions 


Center selects SCHEDULE USING 
SMS, then accepts Release Time 
rTMA updates schedule and sends 
Release Time to SDSS 


Tower ACCEPTS or REJECTS Release 
Time and works to meet time 
SDSS notifies rTMA of Tower action 


Tower initiates Request For Release 
Time via SDSS 

SDSS sends latest OFF time and 
runway predictions to rTMA 


Figure 6:1 - Center and Tower tactical departure scheduling actions with PDRC to 
implement the CFR procedure. 

The tactical departure scheduling actions summarized in Figure 6:1 are described in detail in the 
following subsection. 

6.2 CFR evaluation scenario steps 

This section details tactical departure scheduling with PDRC to implement the CFR traffic 
management procedure. The steps are illustrated with actual screenshots from Tower and Center 
displays taken during the Block 1 PDRC field evaluation. The PDRC scheduling event shown in 
these screenshots is for AAL1001 on 18 June 2012. This was a DFW departure joining an IAH- 
bound stream with outbound tactical departure scheduling (i.e., TMA EDC scheduling) to the 
TNV meter arc, which is situated at the southern boundary of Fort Worth Center very near the 
TORNN arc shown in Figure 3:3. 

As shown in Figure 6:1, the actors in the PDRC operational concept scenario are (nominally) two 
TMCs. One TMC is located in the Center TMU and the other is located in the Tower. For 
simplicity, these TMCs are identified as Center and Tower in the following discussion. 


6.2.1 CFR restriction notification 

The modified CFR notification process will continue to vary by facility. At ZFW, the Center will 
still notify the DIO TRACON, which, in turn, notifies each affected airport Tower that CFR 
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restrictions have been implemented for a given destination and time range. Notifications are done 
via inter-facility voice calls. After the initial notification via DIO TRACON, an individual Tower 
usually communicates directly with the Center when making CFR requests, but multiple towers 
may coordinate through DIO. Both ZFW and DIO will continue to enter the CFR restrictions in 
their electronic logging systems. 

6.2.2 CFR activation in SDSS 

In response to receiving notification of a CFR restriction, the Tower will use the SDSS 
“Add/Remove APREQ Schedule” dialog to enter a new CFR. The CFR will include the 
destination airport or jet route and the time range that is used to determine which flights are 
subject to the CFR restriction. Flights subject to the CFR restriction are entered into a list used 
by rTMA and SDSS to track the flights being actively coordinated. 

The results of CFR activation in SDSS for the AAL1001 example are shown in Figure 6:2. The 
timeline data tag for this flight has been colored white with an APREQ label and APREQ 
appears for AAL1001 in the flights table. 

6.2.3 Request for Release Time (RFRT) 

As an affected flight becomes ready for departure, the Tower will select "Request Release Time" 
from the SDSS “Flight Properties” menu (accessed for a specific flight from the timeline or 
flights table). This causes SDSS to send a Request For Release Time (RFRT) to rTMA. The 
request will include time projections for both Undelayed Coordinated OFF Times (UCOT) and 
Predicted Coordinated OFF Times (PCOT) times. The undelayed time represents when the flight 
could be at the runway assuming no other traffic on the surface, while the predicted time 
incorporates constraints imposed by other aircraft. The flight’s PDRC status is updated, and an 
indication is provided to the Tower on both the timeline and the flights table that the release time 
has been “Requested.” The Center also receives a “Release Requested” indicator on the rTMA 
display as well as an audible alert. 

The SDSS screenshot in Figure 6:2 was captured at 2 1 : 14:37 just as the Tower was selecting 
“Request Release Time” for AAL1001. The PDRC predicted OFF time (i.e., PCOT) is shown in 
the flights table to be 2 1 : 1 9:3 1 . The surface situation display shows that AAL 1001 was just 
beyond the spot when Tower requested the release time. 
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Figure 6:2 - Tower TMC uses SDSS user interface to request release time for 
AAL1001 during the PDRC Block 1 field evaluation. 

The results of the Request Release Time entry are shown in Figure 6:3, which is an SDSS screen 
shot taken a few seconds after the one in Figure 6:2. The timeline data tag and flights table entry 
for AAL1001 have been updated to indicate a pending release time request. The figure also 
shows that the PDRC predicted OFF time is continuously updated - the flights table PCOT value 
for AAL1001 is now 21:19:32. This PCOT value was communicated to rTMA along with the 
release time request. 

Figure 6:3 also illustrates a motivation for using trajectory-based OFF time predictions from a 
surface management system for tactical departure scheduling. AAL1001 is scheduled to depart 
from runway 17R on the east side of DFW. At the time of this screenshot, the 17R departure 
queue is completely empty, and the taxiway from AALlOOl’s position to the departure is also 
vacant. However, the screenshot shows a train of three American Eagle flights currently headed 
to runway 17R along the northernmost bridge (Taxiway Z). In the manual CFR scenario, the 
Tower would have to mentally compute ETAs to the 17R hold pad from these flights on the 
bridge and estimate the departure queue sequence before providing the Center with a predicted 
OFF time for AAL1001. Experienced Tower personnel are adept at these predictions, but the 
extra workload can be eliminated through use of a trajectory-based surface management system. 
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Figure 6:3 - SDSS user interface indicating a pending release time request for 
AAL1001 during the PDRC Block 1 field evaluation. 


6.2.4 Response to the Request for Release Time (RFRT) 

The Center will respond to RFRT requests using rTMA’s “Schedule a Departure” dialog, which 
has been enhanced to display SDSS scheduling information. The Center will select one of the 
following actions: 

• SCHEDULE USING SURFACE TIME, which causes rTMA to schedule the flight for 
departure at the earliest time that is equal to, or later than, the predicted OFF time. If 
the Center FREEZES or ACCEPTS the Suggested Departure Time via the dialog, or 
manually schedules via timeline actions, then rTMA forwards the Scheduled 
Departure Time (SDT) to SDSS. At that point, the flight will be assigned a PDRC 
status of “SDT SENT.” 

• SCHEDULE USING HOST TIME, which allows the TMC to over-ride the surface 
provided OFF time in favor of the ‘now time’ or PTIME default that is adapted in 
TMA. This will also allow the TMC to write in free form text any time they choose. 

• FREE RELEASE, which tells the Tower that the flight may be released at their 
discretion. 


Figure 6:4 is a screenshot of the Center’s rTMA Timeline Graphical User Interface (TGUI) taken 
2 seconds after the SDSS screenshot shown in Figure 6:3. The two left timelines in this figure 
are of interest. The middle timeline has been configured to show IAH-bound traffic that Fort 
Worth Center is managing to satisfy a miles-in-trail (MIT) restriction imposed by Houston 
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Center. Fort Worth Center is seeking to satisfy the MIT restriction for this stream at the TNV 
arc near the boundary between the Centers. The middle timeline is referenced to the TNV arc. 
This timeline represents the constrained overhead stream for this example of the PDRC 
operational scenario. 


Timeline referenced to runway OFF point for 
airports feeding constrained flow to I AH via TNV 
meter point arc 



Figure 6:4 - rTMA user interface indicating a pending release 
time request for AAL1001 during the PDRC Block 1 field 
evaluation. 

The far left timeline in Figure 6:4 shows departures from various airports that Fort Worth Center 
must merge into the constrained IAH-bound stream. The CFR procedure has been implemented 
to manage these departures. This timeline is referenced to the runway OFF point for each of the 
various airports. 

AAL1001 is shown at approximately 21:34 on the left side of the middle timeline. This is the 
time that rTMA estimates AAL1001 could arrive at the TNV arc without consideration for other 
traffic. This ETA is based on rTMA trajectory-based computations that begin with the SDSS- 
provided OFF time prediction. One can see that AAL1001 directly competes with UAL1258, 
which is currently airborne (indicated by leader line and data tag with the same color). 

On the far left timeline AAL1001 is shown with a white data tag indicating that the Tower has 
requested a release time via PDRC. The blue “delay” value shown to the left of the AAL1001 
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data tag provides the Center with an indication of unassigned surface delay that this flight is 
expected to experience due to surface congestion. This value is the difference between PDRC’s 
PCOT and UCOT OFF time predictions. UCOT is computed without consideration of other 
surface traffic while PCOT accounts for other surface traffic. 

The rTMA TGUI screenshot in Figure 6:5 was taken 1 1 seconds after the screenshot in Figure 
6:4. The Center has been notified (via PDRC audible alert) of the pending request for release 
time and activated the Schedule a Departure dialog by double clicking on AALlOOl’s timeline 
data tag. 



Figure 6:5 - rTMA departure scheduling panel prior to Center 
scheduling for AAL1001 during the PDRC Block 1 field 
evaluation. 

As noted in the discussion of Figure 6:3, SDSS has predicted an OFF time of 21:19:32 for 
AAL1001. This OFF time prediction is reflected in Figure 6:5 by AALlOOl’s data tag position 
on the far left timeline and has been automatically loaded into the Aircraft Ready Time field in 
the Schedule a Departure dialog. During the PDRC operational evaluations, rTMA followed 
current TMA practice of displaying only minutes-level precision in the scheduling dialog boxes. 

The rTMA TGUI screenshot in Figure 6:6 was taken 27 seconds after the screenshot in Figure 
6:5. The Center has just clicked on the Schedule button. The “Desired STA” of 2 1 :34 
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corresponds to rTMA’s original estimate of when AAL1001 could reach the TNV arc without 
consideration for other traffic. After the Center scheduling action the Schedule a Departure 
dialog shows the “Closest Available STA to be 2 1 :35 and suggests a departure time of 21:21, 
which corresponds to a 2 minute delay compared to the SDSS prediction (truncated) of 2 1 : 19. 
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Figure 6:6 - rTMA departure scheduling panel after Center 
scheduling for AAL1001 during the PDRC Block 1 field 
evaluation. 

After evaluating the scheduling results, the Center will click the Accept button, which closes the 
Schedule a Departure dialog box and communicates the Scheduled Departure time back to the 
SDSS system at the Tower. The rTMA TGUI screenshot in Figure 6:7 was taken a few seconds 
after the screenshot in Figure 6:6 and shows the results of this tactical departure scheduling 
operation for AAL 1001. Scheduling has now placed AAL 1 00 1 ’ s data tag on the right side of the 
middle timeline. AAL 1001 now has a 2 minute delay as a consequence of being sequenced 
behind UAL 1258. The AAL 1001 data tag on the far left timeline also shows the two minute 
delay and the data tag is positioned at the Scheduled Departure Time of 2 1 :2 1 . 
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Figure 6:7 - rTMA user interface after Center scheduling for 
AAL1001 during the PDRC Block 1 field evaluation. 

This completes the Center’s response to the Tower’s request for release time. 

6.2.5 Response to Scheduled Departure Time (SDT) 

When a Scheduled Departure Time (SDT) is sent to SDSS, the Tower determines if the rTMA- 

supplied SDT is acceptable, and will select one of the following actions: 

• SDT is acceptable, which will prompt notification to the Center and an update of the 
flight’s PDRC status to “SDT ACCEPTED.” On the SDSS display, this will cause the 
timeline data block text to include “APRQ:hh:mm:ss,” where the “hh” is the hour of 
the release, “ mm ” is the minute, and “ss” is the seconds. The data block highlighting 
will indicate whether the flight's current predicted OFF Time is before, after, or within 
a configurable tolerance of the SDT. 

• SDT is not acceptable, which will prompt notification to the Center and an update of 
the flight’s PDRC status to “SDT REJECTED.” In this case, the Tower and Center 
generally resolve the situation via voice communications, however a number of 
automated options exist to resolve this electronically within PDRC. After this 
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Tower/Center coordination, the Center may reschedule the flight, unschedule the 
flight, ‘reset’ the flight, or remove the flight from active SDSS/rTMA coordination. 

• Do nothing. This option was developed during the PDRC Block 1 field evaluation. 
Tower TMCs suggested that explicit acceptance was superfluous. The subject was 
discussed at a field evaluation “how goes it” meeting and Center and Tower personnel 
agreed that this step would be optional. Acceptance of the SDT delivered by rTMA is 
now implied unless the SDT is explicitly rejected. 


The SDSS screenshot shown in Figure 6:8 was taken a few seconds after the rTMA screenshot 
shown in Figure 6:7and slightly more than a minute after the Tower requested a release time for 
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Figure 6:8 - SDSS user interface after receipt of Scheduled Departure Time from 
rTMA for AAL1001 during the PDRC Block 1 field evaluation. 

Figure 6:8 shows that AAL1001 is now proceeding north along taxiway L to runway 17R. The 
SDT computed by rTMA and delivered via the PDRC interface is shown in both the timeline 
data tag and the flights table. The SDT is displayed with seconds-level precision: 21:21 :02. The 
timeline data tag is highlighted in yellow indicating that AAL1001 must be delayed two minutes 
to meet the SDT. 

As described above, the Tower has the option of explicitly accepting the SDT via a right click on 
the timeline data tag. This acceptance would alter the data tag highlight and send a message 
back to rTMA. 
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6.2.6 Departure release management 

Tower traffic control tactics for CFR flights are determined by the Center’s response to the 
RFRT: 

• If a Free Release has been sent from rTMA to SDSS, then the flight’s timeline tag 
reverts to normal text display and “APRQ:FREE” is displayed in the tag. The Tower 
can then manage that flight's departure as if no CFR restriction were in place. 

• If a SDT has been provided and accepted, then the Tower performs tasks to meet the 
rTMA SDT. These may include: flight strip marking and manipulation procedures; 
ATC control of aircraft surface movements, arrivals, and departures; and monitoring 
SDSS’s continuously updated projections of departure time estimates. 

Note that, at any time, rTMA can cancel a RFRT for a particular aircraft via a message to SDSS. 
This will cause SDSS to also cancel the request in a message to rTMA and return the flight to the 
initial state of “APRQ.” The user may then initiate a new request. Note also that at any time 
after a "Request Departure Time" has been initiated, the user may cancel the request. This will 
cause SDSS to send a request cancelation message to rTMA and return the flight to the initial 
state of “APRQ.” 

The SDSS screenshot in Figure 6:9 was taken one minute before the scheduled departure time 
for AAL1001. The aircraft target can be seen in the runway 17R departure queue. AAL1001 is 
next for departure behind EGF3383, which is currently at the 17R threshold. Green highlighting 
for AALlOOl’s timeline data tag indicates the flight is on track to meet the scheduled departure 
time. Near the top of the timeline in Figure 6:9 the data tag for SKW5 169 is colored white with 
an “APRQ” label indicating to the Tower that this is the next flight subject to the CFR procedure. 
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Figure 6:9 - SDSS user interface 1 minute before scheduled departure time for 
AAL1001 during the PDRC Block 1 field evaluation. 


6.2.7 Merge into overhead 

The final step in the tactical departure scheduling scenario involves the merge into the overhead 
stream. This step differs between the inbound and outbound case. For the inbound case, 
scheduled time of arrival and sequence information regarding the merge is communicated to the 
Center sector controller via TMA arrival metering functions. The outbound tactical departure 
scheduling case currently operates in an open loop fashion with no information from TMA EDC 
being communicated to the Center sector controller. For the outbound case, Center TMCs 
carefully monitor the overhead stream merges to identify any traffic management adjustments 
that may be required given current traffic conditions. 

In a similar manner, monitoring of the overhead stream merge is an important performance 
measure for the PDRC field evaluation. Figure 6:10 shows a screenshot of the rTMA Planview 
Graphical User Interface (pGUI) as AAL1001 merged into the IAH-bound overhead stream at 
the TNV meter arc. DFW airport is shown near the top of the screenshot. AAL1001 exited DIO 
TRACON at the DARTZ fix shown near the middle of the diagram. As noted in Section 6.2.4, 
rTMA assigned AAL1001 a two-minute surface delay to resolve a slot contention situation with 
UAL1258. Figure 6:10 shows AAL1001 crossing the TNV arc immediately behind UAL1258 as 
scheduled by rTMA. 
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Figure 6:10 - rTMA planview display showing overhead stream merge for 
AALlOOl during the PDRC Block 1 field evaluation. 
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7 Summary of impacts 

The following sections discuss the operational impacts of this change to system users. 


7.1 Operational impacts 

The change in controller procedures is seen as minimal. The most significant change to current 
operations is incorporating greater precision OFF times into the Tower local controller’s 
workflow. The local controller role is kn own for having a ‘rhythm’ and during the PDRC 
evaluations there was some concern that a highly precise target OFF time might affect this 
rhythm. DFW STMCs prepared briefings on PDRC evaluation procedures presented to all DFW 
Tower controllers. Feedback from the DFW STMCs and TMCs throughout the two operational 
evaluations indicated that these educational efforts were mostly effective, although some 
refresher briefings were required. 

Another procedural change was that phone calls were no longer received by the ZFW Center 
TMU to request for release times. Instead, the Center TMU asked for an audible alert when the 
request for release time arrived from the surface system. The same audible alert option was 
available to DFW Tower personnel for notification of any/all Center events, but they did not feel 
it was needed at this time. 


7.2 Organizational impacts 

Training of system users on the electronic request and scheduling will be required. PDRC 
benefited from the fact that the changes to the Center interface were minimal given the decision 
to utilize rTMA from the FAA’s TMA/EDC system. Even so, training was required to note all 
the differences between TMA and rTMA. The SDSS decision support tool was new to DFW, so 
more extensive training was required for the Tower TMCs. Tower TMCs also had to be trained 
on communication of target times to the local controllers as described in the preceding section. 


7.3 Impacts during development 

The inbound case described earlier in this document has the potential to impact systems outside 
the target facility’s system boundary. For instance, departures being released from DFW into a 
metered arrival flow into IAH would require a receiving TMA system in ZHU. Given that some 
testing of this remote center interface would be necessary prior to production use, and that the 
resulting times would be displayed on operational controllers’ scopes, as they are today for 
manually input times, this requires multi-center coordination. 
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8 Analysis of the proposed system 

The PDRC research activity will assess the value of using surface trajectory-based OFF time 
predictions and runway assignments to compute en route departure schedules during Call For 
Release situations. As the research progresses, results will be documented in this section. Please 
refer to Section 4 for a summary of the anticipated benefits. 


8.1 Summary of improvements 

NASA conducted two operational evaluations of PDRC. The evaluations were based at NASA’s 
NTX Research Station and involved TMCs and FLMs at Fort Worth Center and DFW’s East and 
West Towers. Complete evaluation results are provided in the PDRC Final Report [3]. Specific 
improvements noted the PDRC operational evaluation include the following: 

• The evaluations ran for a total of 29 weeks in 2012 and early 2013. During these 
evaluations more than 230 flights were scheduled with the PDRC prototype. Positive 
subject-matter expert feedback was received throughout the evaluation and significant 
improvements in tactical departure OFF time compliance were demonstrated. 

• OFF time compliance (OTC) is defined as the error between the actual OFF time and the 
coordinated release time agreed to by the Center and Tower TMCs. OTC results from the 
two PDRC evaluations were compared against a year-long sample of baseline data. Since 
the goal is to reduce uncertainty, key OTC metrics are the standard deviation and the 
absolute average error. PDRC showed a 43% improvement over the baseline standard 
deviation and a 43% improvement in absolute average error. 

• A key feature of the PDRC concept is coordination and communication based on a single 
target release time rather than a release window. The PDRC target time (with seconds- 
level resolution) is used throughout the process and a single time (with appropriate 
rounding) is communicated by the Tower TMC/FLM to the local controller. When 
comparing PDRC evaluation results against a present-day standard -2/+1 OFF time 
compliance window we find that 54% of the baseline flights met the -2/+1 window (note 
that outliers were removed from the baseline data set). PDRC Block 1 data exhibited 
74% compliance against the standard window while Block 2 had 83% compliance. By 
this perfonnance measure, PDRC Block 2 exhibited approximately 53% improvement 
over baseline compliance with the standard window. 

• Leveraged surface-provided runway assignments along with more detailed TRACON 
routing to improve en route departure prediction to TRACON departure fix. These 
improvements reduced average TRACON time-to-fly prediction errors by up to a factor 
of 6 (i.e., average errors of 176 seconds reduced to 28 seconds) depending on departure 
runway and departure fix combination. 

8.2 Disadvantages and limitations 

A remaining challenge with surface/en route automation is determining how the processes and 
procedures will differ for equipped sites that have surface automation, versus lesser equipped 
sites that do not. During the PDRC evaluation the EDC system was used for both DFW and non- 
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equipped satellite airports scheduling into the overhead stream. This led Center personnel to 
request seconds-level precision for manual communication to non-surface automation airports. It 
also caused some challenges for the Center due to the less-equipped satellite airports adhering to 
a three minute window while DFW achieved a much higher OFF time compliance than was 
possible without PDRC. 


8.3 Alternatives and trade-offs considered 

Operational alternatives considered during the PDRC evaluation were as follows: 

• Use of a TMA/EDC timeline in the tower. This was considered due to the desire to allow 
greater visibility into the overhead stream for tower personnel. However, after better 
understanding of the complexities of configuring the EDC system for a particular flow 
and the training difficulties associated with that, other options were pursued. 

• Pre-departure conditioning view of surface. A number of alternatives were considered 
with regard to configuring the surface timeline display to make it useful for the TMC in 
his/her everyday work on the airport surface. This entailed a number of GUI changes and 
evaluating a number of options with the TMC in order to arrive at a display that is now 
called ‘pre-departure conditioning.’ This name reflects the TMC use of the surface 
display to perform pre-tactical loading of the runway via assigning aircraft from specific 
departure fixes to one side or the other of the airport. 

• Auto-scheduling. The ability to automatically assign and accept release requests from a 
surface system was implemented in the PDRC system. However, the Center users felt 
that this would not lessen their workload unless DIO TRACON also took over all other 
DIO departures in addition to DFW departures. Therefore, this system option has not 
been fully explored to this point during the PDRC evaluations. 

• Center system or Surface system the primary server. PDRC began with the Center 
system as the primary server of data and the surface system attaching to it later. Over 
time the architecture changed so that the surface system was the server with the Center 
system attaching to it. This seemed more natural to the developers working closely with 
the data. There are no known operational impacts to this architecture change although 
the expected start/stop and uptimes of each system will need to be evaluated as the 
capability is deployed into the NAS. Today, the TMA system can run many days without 
restarting. Restarts in TMA are generally only done when a new adaptation or new 
system software needs to be loaded. The restart policy of the future surface system was 
unknown during PDRC development. 

• Drag and drop for Surface times on TMA. Drag and drop capability is an option 
available for scheduling departures in TMA/EDC today in the NAS. However, use of 
this capability for an aircraft with a surface time would mean that the user is over-riding 
the surface provided time. Consequently, in the PDRC implementation it was decided 
that this capability would not be available. After user feedback on the subject it has 
become apparent that this is a desired feature. 

• Seconds-level precision on the TMA scheduling graphical interface. Center personnel 
requested seconds-level precision on the Schedule a Departure Dialog (SADD) panel. 
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Today the SADD panel always truncates the value to minutes-level granularity. 

However, this variable could not be changed without impacting several areas of the 
source code and due to available resources this change was not made to TMA. 

Route 10B information passed to the surface system. TMA has logic that considers and 
applies changes to the flight’s expected route using flight plan information from the 10B 
field of the NAS flight plan. This information would be useful in the surface system in 
order to properly assign departure fixes. The PDRC system would have benefited from 
this information, resulting in fewer departure fix mismatches. 

Activating a Call For Release electronically from the TGUI. The only phone call that 
still remained in PDRC was to initialize the CFR. This too could be removed by 
allowing the TGUI to create and send this constraint electronically. A reasonable place 
to add this constraint may be on the same panel that is used to assign Miles in Trail. 

Drag and drop on surface timeline. The ability to drag and drop a flight from one time to 
another on the surface timeline was requested by Tower personnel at DFW. This was not 
implemented due to resource constraints. 
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Notes 


See the Technology Description [2] and Final Report [3] for substantial additional information 
that will aid in the understanding of this document. 
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Appendix A: Related NextGen Initiatives 

This appendix discusses NextGen initiatives that are related to the PDRC-IADS research 
activity. 


A.l Integrated Arrival/Departure/Surface Concept 

The FAA NextGen organization is leading an effort to refine the concept [28] and functional 
requirements [29] for Integrated Arrival, Departure, and Surface (IADS) operations. The IADS 
concept is a collection of integrated capabilities designed to assist the air navigation service 
provider, user community, and other stakeholders to efficiently plan for and execute the 
movement of aircraft into and out of congested terminal environments to optimize the use of all 
arrival, departure, and surface capacity. This concept description focuses on how these currently 
separate and independent capabilities will be integrated to operate in a synergistic manner. 

Relationship to PDRC: PDRC seeks to contribute to the development of this concept by 
addressing a portion of the research gaps [30] identified by the FAA NextGen organization. 


A.2 Terminal Flight Data Manager (TFDM) 

The FAA Terminal Flight Data Manager (TFDM) Program is conducting concept engineering 
and requirements analyses to support procurement of a Tower automation system that 
implements the TFDM concept [32]. 

Relationship to PDRC: The NASA/FAA IADS RTT has identified the TFDM program as one 
recipient of the PDRC research transition product (RTP). The TBFM and TFDM Programs will 
use these products to inform development of the Integrated Departure Arrival Capability 
(ID AC), which features linkages between the TBFM and TFDM automation systems. The 
PDRC RTP will be used in TFDM’s Core Work Package. 


A.3 Time Based Flow Management (TBFM) 

The FAA Time Based Flow Management (TBFM) Program provides for continued support and 
development of the Traffic Management Advisor (TMA) decision support tool. 

Relationship to PDRC: The NASA/FAA IADS RTT has identified the TBFM program as one 
recipient of the PDRC research transition product (RTP). The TBFM and TFDM Programs will 
use these products to inform development of the Integrated Departure Arrival Capability 
(ID AC), which features linkages between the TBFM and TFDM automation systems. The 
PDRC RTP will be used in TBFM’s Work Package #3. 


A.4 Integrated Departure Arrival Capability (ID AC) 

The ID AC concept was formerly known as the Departure Flow Management (DFM) concept. 
This can lead to confusion with the recent DFM prototype demonstration and evaluation activity. 
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This section addresses the ID AC concept, while the following section addresses the DFM 
prototype. 

The objective of IDAC is to increase NAS efficiency and reduce delays by providing decision- 
making support capabilities for departure flows. IDAC automates the process of monitoring 
departure demand and identifying departure slots. 

IDAC coordinates the departure times between airports and provides situational awareness to Air 
Traffic Control Towers (ATCT) so that they can select from available departure times in their 
planning. IDAC seeks to leverage and build upon the best of the available FAA departure 
scheduling systems. 

Relationship to PDRC: As described in Section A. 3, the PDRC RTP is intended to support 
TBFM’s development and implementation of IDAC. 


A.5 Departure Flow Management (DFM) prototype 

The DFM prototype has been evaluated in field trials at several FAA facilities. Evaluation 
results are presented in Reference 13, which includes the following description of DFM: 

Departure Flow Management (DFM) is a capability seeking to increase departure flow efficiency 
by automating the coordination of departures from multiple airports over shared and congested 
NAS resources via improved decision support capabilities and web-based, electronic 
communications. Traffic managers in the Center monitor departure and en route demand, initiate 
DFM departure procedures, and monitor the traffic flow. DFM allocates departure times to the 
affected airports, and traffic managers at the airports assign these times to the departures at their 
facilities. Compared to the current APREQ process, the automated calculation, communication, 
and assignment of departure times reduce workload and increase departure flow efficiency. The 
DFM concept builds upon previous NASA research into automation of the APREQ process [20]. 

The DFM prototype, developed by Metron Aviation, was based upon a subset of DFM concept 
requirements that originated from the FAA’s Departure Flow Management Workgroup. The 
goal of the initial operational capability of the Departure Flow Management (DFM) system was 
to satisfy the following principal functions: 

• Allow Center TMCs to electronically submit DFM TMIs 

• Automatically calculate available release times to satisfy TMIs 

• Allow Tower controllers to electronically assign release times 

• Provide a communication protocol to support the automated communication process 

The general concept of the DFM System is outlined as follows (Note: The language below is 
taken directly from the DFM requirements document [36]): 

1 . The DFM System receives flow evaluation area and flight data from ETMS 

2. The Center TMC enters TMIs into DFM 

3. DFM identifies all gaps and release times in the restricted flows 

4. The Center TMC makes and approves release time assignments, and monitors the 
integrity of the flows 
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5. The Tower controller identifies restricted flights and makes release time 
assignments and requests for those flights 

6. The system logs data for post analysis 

7. The Help Desk technician supports Center and Tower users of DFM 

8. The System Administrator user monitors the health of the system and 
troubleshoots any problems 

Relationship to PDRC: As indicated by item 3 above, DFM calculates release times for an 
aircraft in the restricted flows it is managing. However, like the TMA/EDC, DFM has no 
knowledge of the surface situation upon which to base OFF time estimates. PDRC is intended to 
complement the DFM prototype by demonstrating the value of surface trajectory-based OFF 
time predictions and runway assignments for en route tactical departure scheduling. 


A.6 Surface Collaborative Decision Making (Surface CDM) 

The Collaborative Decision Making (CDM) organization has established a working group to 
develop concepts and requirements for Surface CDM [34]. The Surface CDM activity is being 
supported by the FAA’s Surface Office. The Surface CDM working group includes 
representatives from the FAA, air carriers and airport operators. 

Relationship to PDRC: The PDRC -IADS research activity is identifying requirements for two- 
way communications between air carrier systems and the surface and en route components of the 
PDRC concept. The PDRC-IADS research team intends to coordinate with the Surface CDM 
working group to harmonize the concepts and requirements as they continue to be developed. 


A.7 Collaborative Departure Queue Management (CDQM) 

Collaborative Departure Queue Management (CDQM) is one of the capabilities envisioned by 
the FAA’s STBO [31] and TFDM [32] concept of operations. 

CDQM is a technique to manage the length of departure queues at each runway of an airport by 
metering entrance into the airport movement area during times when departure demand exceeds 
available capacity. This metering is accomplished by allocating a “fair share” of the available 
departure capacity to each flight operator based on anticipated demand during a specified 
interval. In addition to equitable capacity allocation among flight operators, there is also 
equitable distribution of delay. In CDQM, aircraft experience minimal physical queuing while 
surface movement management ensures the runway is fully used. Delay can be taken at the gate 
with engines running. 


Relationship to PDRC: PDRC does not directly involve surface traffic management. PDRC is 
narrowly focused on developing a methodology for and demonstrating the benefits of automatic 
communication of trajectory-based OFF time predictions and departure schedules between 
surface and departure management systems. PDRC research products will inform the 
development of advanced surface management capabilities like CDQM. 
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A.8 Spot and Runway Departure Advisor (SARD A) 

NASA’s Safe and Efficient Surface Operations (SESO) research focus area is developing several 
surface optimization capabilities including Spot Release Planner, Runway Scheduler, and 
Taxiway Scheduler. These capabilities are being implemented in NASA’s Surface Management 
System (SMS) research platform for development and evaluation. These optimization functions 
have been evaluated together in a series of Spot and Runway Departure Advisor (SARD A) 
human-in- the-loop simulation experiments at NASA Ames [17]. 


Relationship to PDRC: The PDRC and SESO/SARDA teams are collaborating closely on 
SMS/SDSS software development. PDRC will likely benefit from SMS modeling and trajectory 
synthesis improvements developed for the SESO/SARDA. The PDRC and SARDA research 
teams are working to further integrate the two concepts. For example, PDRC will use SARDA- 
provided estimated pushback times in computing predicted OFF times and SARDA will use 
PDRC coordinated release times as a constraint for spot and runway scheduling. 
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Glossary 

This section provides a list of acronyms and terms relevant to the PDRC-IADS research activity. 
Identical glossaries are being maintained across the PDRC-IADS document family [1, 2, 3]. 


ADIF 

ARTS Data Interface 

APREQ 

ARTCC 

Approval Request - see CFR 

Air Route Traffic Control Center - one of twenty FAA facilities responsible for 
En Route ATC in the NAS 

ATC 

Air Traffic Control 

ATCT 

Air Traffic Control Tower 

CAP 

Collaborative Arrival Planning 

CDIF 

CAP Data Interface 

CDQM 

CFR 

Collaborative Departure Queue Management 

Call For Release - a TMI used to regulate the flow of departures into a 
constrained overhead stream (also known as APREQ). 

ConOps 

CRT 

Concept of Operations 

Coordinated Release Time - the target release time negotiated between Tower 
and Center during CFR operations (see SDT). 

CTD 

Concept and Technology Development (NASA Project) 

DFM 

Departure Flow Management 

EDC 

En Route Departure Capability 

EDIF 

ETMS Data Interface 

ETMS 

Enhanced Traffic Management System - see TFMS 

FLM 

Frontline Manager 

FOSA 

Flight Operator Surface Application - see TSDE 

GUI 

Graphical User Interface 

HDIF 

Host Data Interface 

IADS 

Integrated Arrival/Departure/Surface 

NAS 

National Airspace System 

NextGen 

The next generation air transportation system 

OFF 

Aircraft takeoff time 

OTC 

OFF Time Compliance 

PCOT 

Predicted Coordinated OFF Time 
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PDRC 

PGUI 

RFRT 

RMP 

rTMA 

RTT 

SADD 

SAIE 

SDIF 

SDSS 

SDT 

SMS 

STBO 

TBFM 

TFMS 

TGUI 

TMA 

TMC 

TMI 

TMU 

TRACON 

TSDE 


Precision Departure Release Capability 
Planview GUI 
Request For Release Time 
Research Management Plan 
Research TMA 

Research Transition Team - a joint NASA/FAA activity to facilitate NextGen 
technology transfer 

Schedule a Departure Dialog 

System Analysis Integration and Evaluation (NASA Project) 

Surface Data Interface 

Surface Decision Support System - often used interchangeably with the original 
SMS name. Recently, the FAA STBO Project Office has begun referring to 
SDSS as the NextGen Surface Prototype System (NSPS). 

Scheduled Departure Time - proposed Coordinated Release Time (see CRT) 
computed by TMA and communicated to SDSS by PDRC. 

Surface Management System - see SDSS 

Surface Trajectory-Based Operations 

Time Based Flow Management 

Traffic Flow Management System - replaces ETMS 

Timeline GUI 

Traffic Management Advisor 

Traffic Management Coordinator 

Traffic Management Initiative 

Traffic Management Unit 

Terminal RADAR Approach Control 

Tactical Surface Data Exchange - replaces FOSA 
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